[Previous] [Next] [Index] [Thread]

CGI script cacheing problems (was SECURITY ALERT)

Since we're now on subject of Netscape's cache code, I'd like to add
that when dealing with the output of CGI scripts Netscape has been
handling the session history incorrectly since the first 2.0beta
release.  "Interactive" CGI scripts typically produce a series of
different pages depending on the user input to a series of fill-out
forms.  This can provide the effect of a stateful transaction without
resorting to magic cookies or session keys.  

The session history no longer works correctly with this type of
script.  When the user presses the "back" button, he expects the
previous page to be restored, regardless of the fact that it was
produced by the same URL.  However, Netscape now has two different
behaviors when the user presses the "back" button, both of which are
incorrect.  If the CGI script issued a "no cache" pragma, Netscape
posts a dialog box asking the user if he wishes to send the POST data
again.  If he clicks "OK", the user gets an intrusive dialog box
asking him if he wants to rePOST the data used to generate the page.
If the CGI script did not issue a "no cache" pragma, Netscape's
behavior is much worse: it fetches the _current_ page from the cache,
not the previous one!  In this case, the user is completely unable to
back up in the series of pages generated by the script!

Lincoln

> 
> 
> 
> On Tue, 19 Dec 1995, Wayne Wilson wrote:
> 
> > On Mon, 18 Dec 1995, Jeff Treuhaft wrote:
> > document with it.  That way, when the browser is exited, the session key 
> > is lost and the cached document is now unreadable ... but then you still 
> > have to have a way to delete from the cache ...  In the end, it would 
> > seem simpler to just not cache protected documents in the first place.
> > 
> 
> Not really, some protected pages are the result of a transaction and
> should be visable via the BACK button of the browser in the session
> history.
> 
> For starters, there are two kinds of 'caching' performed in a browser:
> 
> 1.  Backing store for the session history
> 2.  Backing store for minimization of network reload time
> 
> I suspect that many browsers are implemented to combine these two kinds of
> need into a single cache. They need to be isolated so that both good
> usability and privacy can be handled while optimizing network performance.
> 
> The session history is a kind of virtual paper which has the most value if
> the content isn't altered.  After all, if you have a real piece of paper
> on your desk it remains a faithful record unless it is explictly altered.
> The virtual paper of the history should follow the same paradigm w/o respect
> to the protected nature of individual pages. 
> 
> If you accept that fundamental design premise, then it may be possible to
> handle protection of content with some rules like:
> 
> 1. Never save a protected page beyond the scope of a single execution of
>    the UA program.
> 2. Never use DASD for backing store for history purposes for an
>    authorized document. If memory cache space is exhausted, then
>    the history is lost (different UA's could handle error recovery
>    in terms of advising the the user, etc.)
> 
> This of course assumes that the user doesn't leave their machine 'logged'
> in. There is nothing we can do to help such users.
> 
> There is a problem for the UA in determining with certainty that a page
> is protected.  As I read the HTTP draft, if the UA guesses that a request
> will require authentication (e.g., based on URL path) it can provide the
> authentication information w/o waiting for the challenge eliminating a RTT
> but not really knowing if authentication was required.
> 
> But erring on the safe side, the above steps will prevent a correctly
> running UA from leaving a record on DASD or protected information while
> continuing to maximize performance and provide a well behaved user
> interface.
> 
> This will still leave some information providers concerned. I have recently
> learned of a major bank which is concerned that private information might
> be left in memory in the event of a UA abort which results in a core file.
> They are hacking the result by sending the data under cover of an error
> response based on the expectation that:
>   1. UAs will choose to display content associated with a 5xx error
>   2. UAs will not include such responses in the session history.
> While I can think of a lot of reasons why this is probably misdireected
> concern, we probably need to provide response codes or headers which
> prevent inclusion of content in the history. 
> 
> Ultimatately, applications via their servers need two levels of privacy
> control:
>    1.  Don't record on external storage media
>    2.  Don't include in session history
> so that UAs do not need to guess about what should be protected and how. 
> 
> Dave Morris
> 

> 
> Wayne Wilson wrote:
> >   If the issue is one of making network performance optimizations (which
> > is not achieved if you flush before re-access!, then why keep it at all),
> > I would suggest the following compromize to keep the
> > cached document on disk:  establish a session key and encrypt the
> > document with it.  That way, when the browser is exited, the session key
> > is lost and the cached document is now unreadable ... but then you still
> > have to have a way to delete from the cache ...  In the end, it would
> > seem simpler to just not cache protected documents in the first place.
> 
>   We have discussed giving the user the option of encrypting all or part
> of their disk cache.  It may be a feature in some future release, but no
> promises.  If a content provider does not want their pages cached, they
> can send the 'Pragma: no-cache' http header.  If a user does not what them
> cached, they can either disable their cache, or clear it when they are
> done with their session.  I would like to see more control of this
> behaviour put into the hands of the user in some future release.
> 
> 	--Jeff
> 
> -- 
> Jeff Weinstein - Electronic Munitions Specialist
> Netscape Communication Corporation
> jsw@netscape.com - http://home.netscape.com/people/jsw
> Any opinions expressed above are mine.
>
References: